\chapter{Implementierung der NOP-Engine}\label{chapter:impl}
\section{Vorbereitungen zum praktischen Einsatz}
Ausgehend von der Aufgabenstellung soll die NOP-Engine mit der Programmiersprache {\em Java} implementiert werden.
Das Ziel ist eine objektorientierte, plattformunabh"angige und benutzerfreundliche L"osung der NOP-Engine zu erhalten. In diesem Abschnitt werden {\em Java} bzw. mehrere Open-Source-Frameworks von {\em Java} vorgestellt, die f"ur die Implementierung der NOP-Engine mit dem Schichtenmodell von DDD zur Verf"ugung stehen.
\subsection{Java}
{\bf Java} ist eine objektorientierte Programmiersprache. Durch die Java-VM (Java Virtual Machine) laufen Java-Programme in aller Regel ohne weitere Anpassungen auf verschiedenen Computern und Betriebssystemen. In unserem Projekt wird die Version 6.0+ von Java verwendet. Die wichtigsten Merkmale und Vorteile werden im Folgenden beschrieben.

\subsubsection{Objektorientierung}
Die Sprache Java geh"ort zu den objektorientierten Programmiersprachen. Die Grundidee der objektorientierten Programmierung ist die softwaretechnische Abbildung in einer Art und Weise, wie wir Menschen auch Dinge der realen Welt erfahren. Die Absicht dahinter ist, gro"se Softwareprojekte einfacher zu verwalten und die Qualit"at der Software zu erh"ohen. Ein weiteres Ziel der Objektorientierung ist ein hoher Grad der Wiederverwendbarkeit von Softwaremodulen.

\subsubsection{Reflektion}
Java bietet eine {\bf Reflektion}-API \engl{Reflection} als Bestandteil der Laufzeitumgebung. Damit ist es m"oglich, zur Laufzeit auf Klassen und Methoden zuzugreifen, deren Existenz oder genaue Auspr"agung zur Zeit der Programmerstellung nicht bekannt war. H"aufig wird diese Technik im Zusammenhang mit dem Entwurfsmuster "`Factory Method"' angewandt. F"ur die L"osung zum freien Ausw"ahlen der Konkreten Funktion zur Auswertung des Parameters $f$ steht die Reflektion-Technologie zur Verf"ugung. 

\subsubsection{Annotation}
Annotationen kommen ab der Version 5.0+ in {\em Java} zum Einsatz. Sie erlauben die Notation von Metadaten und erm"oglichen bis zu einem gewissen Grad benutzerdefinierte Spracherweiterungen. Sinn der Annotationen ist unter anderem die automatische Erzeugung von Codes und anderen in der Software-Entwicklung wichtigen Dokumenten f"ur wiederkehrende Muster anhand m"oglichst kurzer Hinweise im Quelltext. Insbesondere sind die Annotationen auch "uber die Reflektion-API zug"anglich. Sie werden weit verbreit von Software, Bibliotheken bzw. Open-Source-Frameworks, die auf Java basieren, verwendet. Besonders in {\em Hibernate} und {\em Spring} werden Annotationen zur schnellen Entwicklung und f"ur das O/R Mapping unterst"utzt.
%\subsubsection{Paket}
%Zur besseren Verwaltung der Klassen wird in Java {\bf Pakete} \engl{packages} eingef"uhrt. Ein Java-Paket enth"alt mehrere Klassen, Schnittstellen bzw. Ausnahmen und bildet einen eigenen Namensraum, der normalerweise den Inhalt oder die Verantwortlichkeiten eines Paket beschreibt.

\subsection{Hibernate}
{\bf Hibernate} ist ein Open-Source-Persistenz-Framework f"ur Java. Mit Hibernate wird erm"oglicht, den Zustand eines Objekts in einer relationalen Datenbank zu speichern und aus entsprechenden Datens"atzen wiederum Objekte zu erzeugen, ohne die Datenbank-Zugriffe explizit in SQL programmieren zu m"ussen. Diese Funktionalit"at bezeichnet man auch als Object-Relational Mapping \ab{O/R-Mapping}. Sie befreit den Entwickler von der Programmierung von SQL-Abfragen und h"alt die Applikation unabh"angig vom SQL-Dialekt der verwendeten Datenbank. Bei den Objekten handelt es sich um gew"ohnliche Objekte mit Attributen und Methoden (POJOs). Beziehungen zwischen Objekten werden
auf entsprechende Datenbank-Relationen abgebildet.

\subsubsection{O/R-Mapping}
Zur automatischen Umwandlung zwischen Objekten und Datens"atzen m"ussen Programmierer, die {\em Hibernate} verwenden, intensiv mit dem O/R-Mapping arbeiten. In {\em Hibernate} werden zwei Arten der Anwendungsweisen zur Abbildung von Objekten und Datens"atzen zur Verf"ugung gestellt: entweder mit der XML-Konfigurationsdatei oder mit den Annotationen. Mit der XML werden die Abh"angigkeiten zwischen Objekten und der relationalen Datenbank in einer Konfigurationsdatei ausgelagert, die das XML-Format verwendet. Der Vorteil besteht darin, eine Entkoppelung zwischen dem O/R-Mapping und den Codes zu realisieren. Statt XML kann man auch Java-Annotationen f"ur das O/R-Mapping verwenden. Als Meta-Daten werden die Funktionalit"aten und Strukturen der Java-Klassen nicht von den Annotationen aus {\em Hibernate} verletzt. Der wichtigste Vorteil ist die Einfachheit zur Anwendung solcher Annotationen. Zum Beispiel muss man mit XML f"ur Jeden Enum-Typ ein Interface zum O/R-Mapping realisieren. Dabei m"ussen eine Reihe von Schnittstellen des Interfaces implementiert werden. Im Gegensatz dazu hat man nur eine Annotation {\em @Enumerated(EnumType.ORDINAL)} zu schreiben. Im Projekt NOP-Engine werden  Annotationen von {\em Hibernate} zur schellen Entwicklung verwendet.


\subsection{JavaServer Faces}\label{section:jsf}
{\bf JavaServer} Faces \ab{JSF} ist ein standardisiertes serverseitiges Framework, welches die Entwicklung der Pr"asentationsschicht von Web-Anwendungen vereinfacht. JSF realisiert das Entwurfsmuster "`MVC2"' \cite{Mcgovern03} und sorgt f"ur eine klare Trennung zwischen der Gesch"aftslogik und der GUI-Darstellung. Als ein Framework ist JSF f"ur die Entwicklung und Wiederverwendung von UIKomponenten \engl{User Interface} vorgesehen.  JSF l"auft auf der Server-Seite und wird von vielen h"aufigsten angewendeten Servers wie Tomcat, Glassfish und Oracle Application Server unterst"utzt. Wegen der Einfachheit der Einstellung und Anwendung wird der Server Tomcat f"ur das Gugubarra-Projekt ausgew"ahlt. Die Einstellung von {\em JSF} im Server Tomcat wird im Abschnitt detailliert beschrieben. 



\subsubsection{Verwaltete Beans}
{\bf JavaBeans} ist eine Technologie zum dynamischen Entdecken von Ereignissen und Metadaten durch die wohlgeformte Schreiben-Regel. {\em JSF} verf"ugt "uber JavaBeans, und bietet einen vollst"andigen Mechanismus zur Verwaltung von mit JavaBeans implementierten Objekten. Solche Objekte in JSF werden als die {\bf verwalteten Beans} bezeichnet, und sollen vor dem Starten einer Web-Anwendung in der Konfigurationsdatei von JSF konfiguriert werden.

\subsubsection{Komponenten in JSF}
{\em JSF} ist ein komponentenbasiertes Framework, und bietet umfangreiche vordefinierte Komponenten, die eine oder mehrere graphische Einheiten von HTML kombinieren, um die Eigenschaften der dahinter liegende  verwalteten Beans darzustellen. Die Syntax zur Anwendung dieser Komponenten entspricht der "`HTML 4 Document Type Definition"' \cite{html4}. Jede JSF-Komponente verf"ugt "uber ein Attribut {\em value}, dem ein Name eines darzustellenden Objektes zugewiesen werden kann. Manche besetzen noch ein {\em action} Attribut, mit dem eine Java-Methode verbunden werden soll, um auf ein Ereignis zu reagieren. Diese Java-Methode wird als eine {\em action}-Methode bezeichnet.

\subsubsection{Konverter}
Bei Konverter handelt es sich um eine Java-Klasse, die das Interface {\em Converter} von JSF implementiert, um die Umwandlung zwischen Zeichenketten und darzustellenden Objekten zu erm"oglichen. Solche Klassen verf"ugen "uber zwei Schnittstellen: {\em getAsObject} und {\em getAsString}. Die Schnittstelle {\em getAsObject} ist f"ur die "Uberseztung einer Zeichenkette in einem Objekt zust"andig. Bei {\em getAsString} ist es umgekehrt. 
\subsubsection{Validator}
Ein {\bf Validator} ist ein Pr"ufer, der "uberpr"uft, ob die Eingabe die vordefinierten Bedingungen erf"ullt. In JSF bestehen mehrere M"oglichkeiten zur Anwendung eines Validators. In unserem Projekt werden nur die Standard-Validators von {\em JSF} verwendet, die durch das Attribut {\em validator} f"ur eine Eingabe-Komponente zur Verf"ugung gestellt werden k"onnen.

\subsubsection{Navigation}
Der Prozess der Umleitung \engl{Redirect} von einer Web-Seite zu einer anderen hei"st {\bf Navigation}. {\em JSF} verf"ugt "uber ein elegantes Navigationssystem, das von Ausgaben von {\em action}-Methoden abh"angig ist. Jede Umleitung besitzt eine eindeutige Ausgabe einer einzelnen {\em action}-Methode und einen Verweis auf zwei Web-Seiten: eine Quell-Seite und eine Ziel-Seite. Die drei Eigenschaften einer Umleitung zusammen bilden einen {\bf Navigationsfall} \engl{navigation case}, der f"ur die {\bf Navigationsregel} \engl{navigation rule} einer Web-Site zur Verf"ugung stehen, und in die Konfigurationsdatei von {\em JSF} geschrieben werden soll.

\subsection{Spring}
Das {\em Spring}-Framework ist ein quelloffenes leichtgewichtiges\footnote{Unter Leichtgewicht versteht man, zur Anwendung eines Frameworks m"oglichst wenige vorhandenen Codes zu "andern } Framework f"ur die Java-Plattform. Ziel des {\em Spring}-Frameworks \ab{Spring} ist es, die Entwicklung mit Java/Java EE zu vereinfachen und gute Programmierpraktiken zu f"ordern. {\em Spring} bietet mit einem breiten Spektrum an Funktionalit"at eine ganzheitliche L"osung zur Entwicklung von Anwendungen und Gesch"aftslogiken. Dabei steht die Entkopplung einzelner Programmierger"ustkomponenten im Vordergrund und bietet somit das Zusammenspiel unterschiedlichster Plattformen und Tools: von J2EE-Servern "uber Persistenztools bis hin zur Web-Integration. Das Framework stammt aus dem Buch \cite{Johnson04} von Rod Johnson, und verf"ugt "uber die Prinzipien der Inversion of Control \ab{IoC} \cite{Fowler05} durch die Dependency Injection \ab{DI} und Dependency Lookup \cite{Machacek08}.
\subsubsection{Inversion of Control}
Bei der {\bf Inversion of Control} handelt es sich um ein Prinzip, dass eine Funktion eines Anwendungsprogramms bei einer Standardbibliothek registriert und von dieser zu einem sp"ateren Zeitpunkt aufgerufen wird. Statt dass die Anwendung den Kontrollfluss steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausf"uhrung bestimmter Unterprogramme an das Framework abgegeben. Dieses Prinzip wird von vielen modernen Frameworks verwendet, um leichtgewichtige L"osungen zur Anwendung dieser Frameworks zu bieten.
\subsubsection{Dependency Injection}
{\bf Dependency Injection} ist ein Entwurfsmuster und dient dazu, die Abh"angigkeiten zwischen Komponenten oder Objekten aus Codes auszulagern und zu minimieren. Dependency Injection ist eine Anwendung des Prinzips der IoC, bezieht sich aber nur auf die Erzeugung und Initialisierung von Objekten. In {\em Spring} werden Zwei Arten der Dependency Injection implementiert: Contructor DI und Setter DI.
\subsubsection{Dependency Lookup}
Bei der {\bf Dependency Lookup} \ab{DL} handelt es sich um einen Mechanismus, mit dem ein registriertes Objekt in einem gewissen Kontext wiedergefunden werden kann.\\\\
Durch die Dependency Injection und Dependency Lookup werden die registrierten Objekte in ihren Lebenszyklen von {\em Spring} verwaltet und gesteuert. F"ur die Anwendung von DI und DL stehen in {\em Spring} {\bf BeanFactory} und {\bf Beans} zur Verf"ugung. Unter Beans versteht man die Objekte, die unter {\em Spring} verwaltet werden, und bei der BeanFactory handelt es sich um einen Container, in dem die Beans registriert und wiedergefunden werden k"onnen.\\\\
Im Projekt NOP-Engine wird das Framework {\em Spring} als Hilfsmittel zur Verwaltung der Objekte bzw. ihrer Abh"angigkeiten, zum Integrieren der Schnittstellen verschiedener Schichten und zum Testen der Funktionalit"aten der NOP-Engine verwendet.


\section{Implementierung der Services der Dom"annenschicht zur Berechnung von NOPs}
Die Klassen f"ur die Entit"aten und Wert-Objekte anzulegen ist eine reine Tastenanschlagarbeit. Hierbei konzentrieren wir uns auf die Implementierung der Services\footnote{Die Begriffe Entit"at, Wert-Objekt, Service und Repository werden im Kapitel \ref{chapter:design}, Abschnitt \ref{section:ddd} beschrieben.}. 
\subsection{Implementierung der Services zur Anpassung der Performance}
Alle Services im Paket \kc{de.gugubarra.core.nop.service}dienen zur Berechnung von NOPs. Im Kapitel \ref{chapter:requirment} wird erw"ahnt, dass die Berechnung von NOPs nicht von den Benutzer einer Web-Site bzw. dessen Benutzer-Sessionen abh"angig sein darf. Im folgenden Codeblock steht die Implementierung der Start-Funktion\footnote{Die Start-Funktion und ihre Subroutinen werden im Kapitel \ref{chapter:algo}, Abschnitt \ref{section:algo} erl"autert.} {\em calculateNops} des Kern-Algorithmus.\\
\includeJavaCode{chapters/implement/dependencyOfUser.java}{Die Implementierung des Algorithmus zur Berechnung von NOPs}{jc:performance}
In der Zeile zwei wird eine Benutzer-Session durch die Schnittstelle \kc{getUserSessionAfter}vom Repository herausgefunden. Sie soll "uber eine kleinste Endzeit verf"ugen, die gr"o"ser als der Aktualisierungszeitpunkt des eingegeben NOP-Projekts sein muss. Dann folgt eine {\em If-}Bedingung zum Kontrollieren, ob so eine Benutzer-Session vorhanden ist. Wenn Ja, soll diese Benutzer-Session zur Berechnung von NOPs beitragen, und das Programm weiter durchgef"uhrt werden. Ansonsten wird es abgebrochen. In der Schleife wird diese Bedingung immer "uberpr"upt, bis solche Benutzer-Sessionen nicht mehr existieren. Dabei wird jedes Mal nur eine Benutzer-Session aus dem Repository herausgeholt (Zeile 9), und eine Auflistung aller Benutzer-Sessionen vermieden. Die anderen Services sind nur abh"angig von dieser herausgefundenen Benutzer-Session, und die Anforderung der Performance ist erf"ullt.
\subsection{L"osung zum freien Ausw"ahlen einer konkreten Funktion f"ur den Parameter $f$}
Im letzten Kapitel wird das Problem zum freien Ausw"ahlen einer konkreten Funktion f"ur den Parameter $f$ mit dem Entwurfsmuster "`Strategy"' auf der Entwurfsebene gel"ost. Hierbei wird die Implementierung dieser L"osung mit den folgenden Codes ausf"uhrlich beschrieben.
\subsubsection{Implementierung der konkreten Funktion f"ur den Parameter $f$ mit dem Entwurfsmuster "`Singleton"'}
Zun"achst erstellen wir f"ur jede konkrete Realisierung des Interfaces {\em ICalculateF} eine statische Methode {\em geinstance}, die das Entwurfsmuster "`Singleton"' \cite{Gamma94} wie in dem folgenden Code dargestellt implementiert.\\
\includeJavaCode{chapters/implement/paramFunc.java}{Die Implementierung einer konkrete Funktion zur Auswertung des Parameters $f$ mit dem Entwurfsmuster "`Singleton"'}{jc:pf1}
Dadurch wird f"ur das Gesamtsystem nur eine Instanz einer konkreten Funktion f"ur den Parameter $f$ zur Verf"ugung gestellt, und alle Funktionen besitzen eine Methode mit einem einheitlichen Namen {\em getInstance}, mit dem der Aufruf dieser Methode ohne Initialisierung der Klasse durch Java-Reflektion erm"oglicht.
\subsubsection{Implementierung der Schnittstelle des Interfaces \kc{IGetParamFFunc}mit der Reflektion}
Die folgende Methode implementiert die Schnittstelle des Interfaces {\em IGetParamFFunc} mit der  Java-Reflektion. Ab der Version 6.0 soll diese Implementierung durch die Annotation \anno{Override} deklariert werden. Nach der Ausf"uhrung der Zeilen 3 und 4 wird eine Instanz der Methode \kc{getInstance}einer konkreten Funktion f"ur den Parameter $f$ mit dem eingegeben vollst"andigen Klassennamen erzeugt. In der Zeile 5 wird die Methode \kc{getInstance}durch den Aufruf der Schnittstelle \kc{invoke}dieser Methodeninstanz ausgef"uhrt, und eine Instanz der zu suchenden konkreten Funktion f"ur den Parameter $f$ zur"uckgegeben.\\
\includeJavaCode{chapters/implement/GetParamFImp.java}{Die Realisierung des Interfaces {\em IGetParamFFunc} durch {\em Reflection}}{jc:pf2}

\subsubsection{Verwaltung der Funktionen f"ur den Parameter $f$ in dem {\em SystemController}} 
Die Funktionen f"ur den Parameter $f$ werden durch ein {\em HashMap} vom Objekt {\em SystemController} verwaltet. In der Zeile 2 des Codes in der Liste \ref{jc:pf3} wird eine Instanz von \kc{HashMap}deklariert, wobei der Schl"ussel von \kc{HashMap}der Name zur Darstellung einer Funktion auf einer Web-Seite ist, und der Wert von {\em HashMap} den vollst"andigen Klassennamen dieser Funktion bezeichnet. Auf dieser Deklaration steht eine Annotation {\em @Resource}, die f"ur eine automatische Ladung einer registrierten Bean zust"andig ist. Dabei m"u"sen das Attribut {\em id} der Bean und der Name der deklarierten Eigenschaft "`paramFMap"' gleich sein.\\
\includeJavaCode{chapters/implement/getParamFKey.java}{Mapping der Funktionen f"ur den Parameter $f$ mit den Namen zur Darstellung auf eine Web-Seite}{jc:pf3}
In der Liste \ref{xml:pf4} wird eine Bean mit einem {\em id} "`paramFMap"' f"ur ein {\em HashMap} in der {\em BeanFactory} von Spring registriert. In der Zeile 2 und 3 wird der Klasse {\em DefaultCalculateFImp} der Name "`Default Function"' zur Darstellung auf der Web-Seite durch ein "`entry"'-Element zugewiesen. Durch diese Einstellung soll das Objekt {\em SystemController} nach der Initialisierung automatisch "uber zwei Funktionen f"ur den Parameter $f$ verf"ugen. Um eine Funktion f"ur den Parameter $f$ einzuf"ugen oder zu entfernen, soll man in diesem Block eine neue "`entry"' erstellen oder eine vorhandene "`entry"' streichen. Die Konfiguration zur Anwendung der Beans von {\em Spring} in {\em JSF} wird im Abschnitt \ref{section:spinjsf} erl"autert.\\
\includeXml{chapters/implement/getparamFSpring.xml}{Die registrierte Bean f"ur ein {\em HashMap} in Spring}{xml:pf4}
\subsubsection{Ausw"ahlen einer Funktion f"ur den Parameter $f$}
Beim Anlegen eines NOP-Projekts muss man dabei so eine Funktion f"ur den Parameter $f$ ausw"ahlen, und sie in der Strategie des NOP-Projekts hinzuf"ugen. Auf der Web-Seite werden nur die Namen der Funktionen dargestellt. Nach dem Selektieren einer Funktion soll die Eigenschaft "`paramFKey"' der Strategie "uber den vollst"andigen Klassennamen dieser Funktion verf"ugen.
\subsubsection{Anwendung des Entwurfsmuster "`Strategy"' zur Auswertung des Parameters $f$}
Der folgende Codeblock dient zur Implementierung der Methode {\em getParamF} f"ur die Klasse {\em strategy}. In der Zeile 1 wird die Funktion mit ihrem vollst"andigen Klassennamen, der in der Eigenschaft {\em paramFKey} gepeichert ist, f"ur den Parameter $f$ durch den Aufruf der Methode {\em getFFunc} herausgefunden. Danach wird die Schnittstelle {\em getValue} von dem Interface {\em ICalculateF} aufgerufen, und der Wert des Parameters $f$ zur"uckgegeben. Dann wird das Entwurfsmuster "`Strategy"' implementiert. Dadurch werden alle Informationen der Konkreten Funktionen zur Auswertung des Parameters $f$ versteckt, sodass diese Auswertung nicht mehr von der konkreten Funktion abh"angig ist.\\
\includeJavaCode{chapters/implement/strategyPf.java}{Auswertung des Wertes des Parameters $f$ in der Klasse Strategie}{jc:pf5}
Hierher wird das Problem zum freien Ausw"ahlen der konkreten Funktion zur Auswertung des Parameters $f$ gel"ost. Zum Einf"ugen einer neuen Funktion oder Entfernen einer alten ist eine Ver"anderung der vorhandenen Java-Codes nicht erforderlich.


\section{Anwendung von Hibernate zum Zugreifen auf die Datenbank}
In unserem Projekt wird Hibernate als Persistenz-Framework zur Implementierung der Persistenzschicht angewendet. Mit den folgenden drei Schritten wird Hibernate zum Einsatz gebracht:
\begin{enumerate}
\item Konfigurieren der SessionFactory zur Anbindung an die Datenbank
\item O/R Mapping f"ur die Entit"aten und ihre entsprechenden Datenbanktabellen
\item Anwendung von Hibernate zum Manipulieren der Entit"aten
\end{enumerate} 
Die Aufgabe des ersten Schrittes wird bei der Integrationsphase von Spring "ubernommen. Im Folgenden werden  nur der zweite und dritte Schritt detailliert beschrieben.
\subsection{O/R Mapping f"ur die Entit"aten}
In Hibernate werden zwei Mechanismen zum O/R Mapping zur Verf"ugung gestellt.
\begin{itemize}
\item Mapping mit "`public"' Eigenschaften
\item Mapping mit "`public"' {\em getter-}Methoden
\end{itemize}
Wegen des Prinzips der Kapselung sind die Eigenschaften aller Klassen "`private"' vorgesehen. In der vorliegenden Arbeit wird nur das Mapping mit "`public"' {\em getter-}Methoden verwendet. Es sind, wie in der Vorbereitungsphase erw"ahnt, nur die Annotationen von {\em Hibernate} zum O/R Mapping zum Einsatz gekommen.
\subsubsection{Mapping einer Klasse mit der entsprechenden Datenbanktabelle}
Die im letzten Kapitel herausgefundenen Entit"aten und ihre entsprechenden Datenbanktabellen sollen durch die Annotation \anno{Entity}bzw. \anno{Table} von {\em Hibernate} abgebildet werden. Beide Annotationen m"ussen vor der Deklaration einer Klasse stehen. Zum Beispiel  wird in der Liste \ref{jc:entity} das Mapping der Klasse {\em Zone} mit der Tabelle "`zones"' dargestellt. Dabei verweist das Attribut {\em name} der Annotation \anno{Table} den Namen der entsprechenden Datenbanktabelle.\\
\includeJavaCode{chapters/implement/entity_zone.java}{Beispiel: Mapping der Klasse {\em Zone} mit der Datenbanktabelle "`zones"'}{jc:entity} 

\subsubsection{Mapping einer Eigenschaft mit einer Spalte einer Datenbanktabelle}
F"ur dieses Mapping steht in Hibernate die Annotation \anno{Column}zur Verf"ugung. Manche spezielle Datentypen in Java sowie {\em Date} bzw. {\em enum} verf"ugen noch "uber eigene zus"atzliche Annotationen.
\includeJavaCode{chapters/implement/column.java}{Beispiel: Mapping eines Datentyps mit einer Spalte einer Datenbanktabelle}{jc:col}
In der Liste \ref{jc:col} stehen zwei Beispiele aus der Klasse "`TopicZoneWeight"'. Die Eigenschaft {\em weight} verf"ugt "uber einen einfachen Datentyp {\em float}, und braucht nur die Annotation \anno{Column.}Dabei verweist das Attribut {\em name} auf den Namen einer Spalte der entsprechenden Datenbanktabelle. Im Vergleich mit diesem Datentyp {\em float} ist eine zus"atzliche Annotation \anno{Temporal} f"ur die Eigenschaft {\em created} mit einem {\em Date} Typ erforderlich.

\subsubsection{Mapping einer Eigenschaft als Prim"arschl"ussel}
Jede Entit"at verf"ugt "uber einen Schl"ussel als Identit"at. Dieser Schl"ussel wird als der Prim"arschl"ussel der entsprechenden Datenbanktabelle betrachtet. Zum Mapping des Schl"ussels einer Entit"at soll eine Kombination der Annotation \anno{Id}und \anno{Column}verwendet werden, so wie in der Liste \ref{jc:pk} dargestellt.\\
\includeJavaCode{chapters/implement/id_zone.java}{Beispiel: Mapping der Eigenschaft {\em id} mit dem Prim"arschl"ussel der entsprechenden Datenbanktabelle}{jc:pk}

\subsubsection{Mapping einer Eigenschaft mit einer Entit"at}
Im letzten Kapitel werden alle Aggregate aus der Problemdom"ane f"ur die NOP-Eingine herausgefunden. In Hibernate werden die Entit"aten anhand solcher Aggregate mit den entsprechenden Datenbanktabellen abgebildet.\\ 
\includeJavaCode{chapters/implement/nop_manytoone.java}{Beispiel: Mapping einer Eigenschaft mit einer Entit"at mit der Beziehung "`many to one"' }{jc:manytoone}
Das Beispiel in der Liste \ref{jc:manytoone} beschreibt die Beziehung "`many to one"'\footnote{Die wichtige Beziehungen zwischen den Entit"aten werden im Kapitel \ref{chapter:design}, Abschnitt \ref{section:aggregate} erl"autert.} zwischen einem NOP und einem NOP-Projekt durch die Annotation \anno{ManyToOne.}Dabei wird eine Beschr"ankung f"ur die entsprechende Tabelle der Klasse {\em Nop} automatisch generiert. Die Annotation \anno{JoinColumn}in der Zeile 2 steht f"ur eine Deklaration eines Fremdschl"ussels in der dem NOP entsprechenden Tabelle zur Verf"ugung.  F"ur die Beziehung "`one to one"' soll nur anstatt der Annotation \anno{ManyToOne}, \anno{OneToOne} verwendet werden. Dieses Mapping ist f"ur die im Abschnitt \ref{section:aggregate} herausgefundenen Beziehungen "`many to one"' oder "`one to one"' von den Entit"aten zustandig.

\subsubsection{Mapping einer Eigenschaft mit Entit"aten als ein Collection-Typ}
F"ur die im letzten Kapitel erw"ahnten Beziehungen "`one to many"' und "`many to many"' zwischen den Entit"aten steht dieses Mapping zur Verf"ugung. Ausgehend von dem Klassendiagramm in der Abbildung \ref{figure:classes} ist eine Beziehung "`one to many"' zwischen {\em UserSession} und {\em DurationInfo} festgehalten. Die Klasse {\em UserSession} verf"ugt "uber eine Eigenschaft {\em durationInfos} mit dem Java-Typ {\em Set}, die alle betroffenen {\em DurationInfo}-Objekte enthalten soll. In der Klasse {\em UserSession} steht der folgende Code zur Deklaration dieser Beziehung durch die Annotation {\em @OneToMany}. \\
%Wir sehen das Aggregat f"ur die Entit"at "`Nop"' an. Die Beziehung zwischen "`Nop"' und "`Topic"' ist "`many to many"'. In der Klasse "`Nop"' werden alle bez"ugliche "`Topics"' durch ein \kc{Map}verwaltet. In der Liste \ref{jc:manytomany} wird die "`many to many"' Beziehung zwischen "`Nops"' und "`Topics"' durch die Annotation \anno{ManyToMany}bezeichnet. Das Attribut "`mappedBy"' von \anno{ManyToMany} zeigt an, dass jedes "`Nop"' diese Beziehung weisst, aber "`Topic"' nicht.  \\
\includeJavaCode{chapters/implement/nop_manytomany.java}{Beispiel: Mapping einer Eigenschaft als ein {\em Conllection}-Typ f"ur die Beziehung "`one to many"'}{jc:onetomany}
Dabei werden noch zwei Attribute dieser Annotation verwendet. {\em mappedBy} bezeichnet den Namen der Eigenschaft der Klasse {\em DurationInfo}, die auf eine {\em UserSession} verweist. Mit {\em cascade=CascadeType.All} wird eine Beschr"ankung f"ur die {\em UserSession} und {\em DurationInfo} der entsprechenden Datenbanktabellen erstellt, die zur automatischen Ladung der betroffenen {\em DurationInfo} Objekte dient, wenn ein {\em UserSession} Objekt aus der Datenbank wiedergefunden wird.
%Der Code in der Liste \ref{jc:onetomany} zeigt diese "`many to many"' Beziehung an. Ausgehend von der Definition besteht ein NOP Mit der Annotation \anno{ManyToMany}
\subsubsection{L"osung zur Historisierung der Zonen und Aktionen}
Im letzten Kapitel wird eine L"osung zur Historisierung von Aktionen und Zonen vorgestellt. Die Klassen {\em Zone} und {\em Action} sollen nur "uber zwei weitere Eigenschaften verf"ugen. In der Klasse {\em Zone} stehen eine Eigenschaft {\em zone\_id} und eine {\em version}. In der Klasse {\em Action} sind {\em action\_id} und {\em version}. Sie k"onnen auch als die Schl"usselkandidaten der entsprechenden Datenbanktabellen betrachtet werden. Dadurch werden die Instanzen der {\em Zone} oder {\em Action} eindeutig bestimmt. Auf die Zonen und Aktionen kann von der NOP-Engine nicht direkt zugegriffen werden. Nur aus Benutzer-Sessionen kann die NOP-Engine diese Informationen erhalten. Mit anderen Worten sollen alle betroffenen Zonen und Aktionen beim Wiederfinden einer Benutzer-Session automatisch geladen werden.  Im folgenden Codeblock wird eine Zeitdauerinformation mit den betroffenen Zonen abgebildet.\\
\includeJavaCode{chapters/implement/dur_zone.java}{Beispiel: Mapping der historisierten "`Zones"'}{jc:durzone}
In der Zeile 2 ist eine neue Annotation \anno{JoinTable}zum Einsatz gekommen. Damit wird die Beziehung zwischen Zonen und Zeitdauerinformationen in der Tabelle {\em visit\_zones} gespeichert. In der Zeile 4 wird der Prim"arschl"ussel dieser Tabelle als ein Fremdschl"ussel der Zeitdauerinformationen der entsprechenden Tabelle dargestellt. Das Attribut {\em inverseJoinColumns} enth"alt die Schl"usselkandidaten {\em zone\_id} und {\em version}. Damit wird eine Zeitdauerinformation mit den betroffenen Zonen zusammen geladen. F"ur das Mapping der Aktionsinformationen mit Aktionen wird wegen der Beziehung "`one to many"', die Annotation \anno{OneToMany}anstatt \anno{ManyToMany}  verwendet. 
\subsection{Anwendung von Hibernate zur Implementierung der Persistenzschicht der NOP-Engine}\label{section:usehi}
Das Interface {\em IPersistenceTool} beinhaltet alle Schnittstellen der Persistenzschicht zum Speichern und Wiederfinden der Entit"aten der Dom"anenschicht. Die Implementierung dieser Schnittstellen ist stark von den Objekten sowie \kc{Session,}\kc{Transaction,}\kc{Criteria,}\kc{Restrictions}und \kc{Projection}von {\em Hibernate} abh"angig.
\subsubsection{Erhalten und Abschlie"sen eine {\em Session-}Instanz}
In {\em Hibernate} steht f"ur den Zugriff der Datenbanktabellen das \kc{Session}Objekt zur Verf"ugung, das die Anfragen erstellen kann, und fast "uberall bei der Anwendung von {\em Hibernate} verwendet wird. Zum Erhalten einer \kc{Session-}Instanz wird der folgende Code eingesetzt. Die \kc{Session-}Instanz wird durch ein \kc{ThreadLocal}Objekt verwaltet, mit dem nur auf die diesem Thread zugeh"orende \kc{Session-}Instanz zugegriffen werden darf. In der Zeile 7 wird eine neue \kc{Session-}Instanz durch den Aufruf der Schnittstelle \kc{openSession}der \kc{SessionFactory}erstellt. Diese Methode soll f"ur alle weiteren Anfrage-Methoden zur Verf"ugung stehen.\\
\includeJavaCode{chapters/implement/hisession.java}{Erhalten einer Session-Instanz von Hibernate}{jc:hisession}

\subsubsection{Speichern einer Entit"at mit dem {\em Session} Objekt}
Die Methode \kc{save}kann direkt durch den Aufruf der Schnittstelle {\em saveOrUpdate} einer {\em Session-}Instanz implementiert werden. Damit wird eine neue Instanz einer Entit"at gespeichert oder eine alte Instanz aktualisiert.  Welche Operation ausgef"uhrt wird, soll von Hibernate selbst entschieden werden. Dabei wird noch die Klasse {\em Transaction} angewendet, um m"ogliche Fehler abzufangen und den Zustand der entsprechenden Datenbanktabelle wiederherzustellen.\\ 
\includeJavaCode{chapters/implement/hisave.java}{Implementierung der Methode {\em save}}{jc:hisave}
Die Methode {\em save} ist f"ur die Schnittstellen des Repositorys "`INopEngineRep"' sowie {\em saveNop} und {\em saveNopProject} zust"andig.
\subsubsection{Wiederfinden einer Entit"at durch den Schl"ussel}
Zum Wiederfinden einer Entit"at durch den Schl"ussel kann man direkt die Methode {\em get} von {\em Session} mit den Parametern, dem Typ und dem Schl"ussel der Entit"at aufrufen. Dabei beschreibt {\em Class$<$T$>$} den Typ einer Entit"at.  \\
\includeJavaCode{chapters/implement/findid.java}{Wiederfinden einer Entit"at durch den Schl"ussel}{jc:findid}
\subsubsection{Wiederfinden aller Entit"aten eines Typs}
Die folgende Methode dient zum Wiederfinden aller Entit"aten eines Typs. In diesem Fall ist keine weitere Bedingung erforderlich. Durch den Aufruf der Methode {\em list} von {\em Criteria} wird diese Aufgabe erf"ullt.\\
\includeJavaCode{chapters/implement/findall.java}{Wiederfinden aller Entit"aten eines Typs}{jc:hifindall}
\subsubsection{Wiederfinden der Entit"aten durch die eingegebenen Bedingungen}
Zum Erstellen der Bedingungen einer Anfrage mit {\em Hibernate} werden normalerweise {\em Criteria}, \kc{Restrictions}und \kc{Projection}verwendet. Wobei \kc{Criteria}ein Beh"alter ist, der die Bedingungen einer Anfrage enth"alt. {\em Restrictions} und \kc{Projection}dienen dazu, verschiedene Bedingungen anzulegen.
%Im letzten Kapitel wurde eine Reihe von den \kc{find-}Schnittstellen der "`IPersistenceTool"' durch das dynamische Binden dargestellt. Wir konzentrieren uns hierbei auf die Implementierung solcher \kc{find-}Operationen mit Hibernate.
Im folgenden Codeblock wird die Schnittstelle {\em findByProperties} implementiert. Dabei werden eine Reihe von Gleich-Bedingungen durch eine Schleife mit der Methode {\em add} von {\em Criteria} bzw. der statischen Methode {\em Restrictions.eq} erstellt.\\
\includeJavaCode{chapters/implement/findprops.java}{Wiederfinden der Entit"aten durch Gleich-Bedingungen}{jc:findprops}
Das Wiederfinden einer speziellen Benutzer-Session oder des aktuellen NOPs eines Benutzers ist ziemlich kompliziert. In der Liste \ref{jc:findlast} steht die Implementierung der Methode {\em findNeighbor}, die daf"ur zust"andig ist. Zwischen den Zeilen 5 und 7 werden die normalen Gleich-Bedingungen erstellt. Danach muss mal beurteilt werden, welcher Nachbar, vor oder nach dem eingegebenen Zeitpunkt {\em limit},  herausgefunden werden soll. Daf"ur stehen die statischen Methoden {\em Restrictions.le} bzw. {\em Restrictions.gt} und {\em Projections.max} bzw. {\em Projections.min} zur Verf"ugung. Die Methode {\em le} erstellt eine Bedingung "`vor"', und {\em gt} eine "`nach"'. Mit den Methoden {\em max} oder {\em min} wird eine Beschr"ankung f"ur die Anfrage dargestellt: entweder der gr"o"ste Zeitpunkt vor dem {\em limit} oder der kleinste nach dem {\em limit}. Durch diese erste Anfrage wird nur der Zeitpunkt des richtigen Objekts zur"uckgeliefert. Zum Wiederfinden des richtigen Objektes soll eine weitere Anfrage, wie zwischen den Zeilen 17 und 20 dargestellt werden, Diese wird aufgebaut und enth"alt au"ser den normalen Gleich-Bedingungen noch eine neue Gleich-Bedingung mit dem herausgefundenen Zeitpunkt. Damit wird der richtige Nachbar f"ur den eingegebenen Zeitpunkt wiedergefunden.\\
\includeJavaCode{chapters/implement/findLastBefore.java}{Wiederfinden der Entit"aten durch Gleich-Bedingungen}{jc:findlast}
%\includeJavaCode{chapters/implement/findFirstAfter.java}{Wiederfinden der Entit"aten durch Gleich-Bedingungen}{jc:findfirst}
\subsubsection{L"osung zur Historisierung der NOP's}
Die Instanzen der NOP's k"onnen auf die NOP-Engine direkt durch die Schnittstelle {\em getCurrentNop} des Interfaces {\em INopEngineRep} zugreifen. Daf"ur steht die Methode {\em findNeighbor} der Klasse {\em persistenceToolImp} zur Verf"ugung. Zum Bestimmen eines aktuellen NOP eines Benutzers in Bezug auf ein NOP-Projekt ist noch eine weitere Eigenschaft {\em created} erforderlich. Dies ist der gr"oste Zeitpunkt vor dem Aktualisierungszeitpunkt des NOP-Projekts. Dabei wird der Parameter {\em isBefore} der Methode {\em findNeighbor} {\bf false} gesetzt, um eine Bedingung "`vor dem Zeitpunkt"' in der Anfrage zu erstellen. Im speziellen Fall wird ein {\em null} Objekt zur"uckgegeben, d.h. noch kein NOP wird f"ur das eingegebene NOP-Projekt und den Benutzer berechnet. \\
\includeJavaCode{chapters/implement/getNop.java}{Wiederfinden der Entit"aten durch Gleich-Bedingungen}{jc:getNop} 
\section{Integrieren der Schnittstellen verschiedener Schichten durch {\em Spring}}\label{imp:integration}
In unserem Projekt soll {\em Spring} die Aufgaben der Applikationsschicht "ubernehmen. Alle Objekte, die zu der Dom"anenschicht und Persistenzschicht geh"oren, bzw. ihre Abh"angigkeiten sollen unter {\em Spring} verwaltet werden.
\subsubsection{Konfigurieren von Hibernate f"ur die Persistenzschicht durch die Datenquelle}
Die Definition einer Datenquelle ist ein wichtiger und kritischer Teil zur Verbindung einer Datenbank. Spring bietet daher eine konsistente Verfahrensweise an, wie Datenquellen definiert werden k"onnen. Im folgenden Codeblock in der Liste \ref{conf:datasource} wird die Verwendung von DBCP gezeigt. Sie wird f"ur die Verbindung einer MYSQL-Datenbank zur Verf"ugung gestellt.\\
\includeXml{chapters/implement/datasource.xml}{Konfigurieren einer Datenquelle f"ur Hibernate in Spring}{conf:datasource}
Zur Anwendung dieser Datenquelle  bietet {\em Spring} eine eigene Implementierung f"ur das Interface {\em SessionFactory} von {\em Hibernate}, die durch die folgende Einstellung mit der vordefinierten Datenquelle zusammenarbeiten kann. In der Zeile 3 steht der vollst"andige Klassenname dieser Implementierung von {\em SessionFactory}, die noch die Annotationen zum O/R Mapping unterst"utzt. Zwischen den Zeilen 4 und 6 wird die vordefinierte Datenquelle {\em dataSource} als eine Eigenschaft dieser {\em SessionFactory} deklariert.\\
\includeXml{chapters/implement/sf_spring.xml}{Einstellung der {\em SessionFactory} mit der vordefinierten Datenquelle}{conf:sf}
Dabei werden noch weitere Einstellungen in der {\em SessionFactory} f"ur {\em Hibernate} zur Verf"ugung gestellt. Zwischen der Zeile 2 und 6 in der Liste \ref{conf:annoclass} werden alle Entit"aten durch eine Liste in der {\em SessionFactory} registriert. Im Block von der Zeile 8 bis 13 lassen sich die Eigenschaften von {\em Hibernate} einstellen, z.B. der Anfrage-Dialekt f"ur die MYSQL-Datenbank.\\
\includeXml{chapters/implement/annoclass.xml}{Einstellung der {\em SessionFactory} zur Anpassung an {\em Hibernate}}{conf:annoclass}
Schlie"slich wird diese vordefinierte \kc{SessionFactory} als eine Eigenschaft der in {\em Spring} registrierten Bean \kc{persistenceTool,}hinzugef"ugt, die die Schnittstelle der Persistenzschicht \kc{IPersistenceTool}realisiert.\\
\includeXml{chapters/implement/pt_sp.xml}{Anwendung der vordefinierten {\em SessionFactory} f"ur die Schnittstelle der Persistenzschicht}{conf:pt}
\subsubsection{Integrieren der Schnittstellen der Dom"anen- und Persistenzschicht}
Zum Integrieren der Schnittstellen der Dom"anen- und Persistenzschicht sollen zwei weitere Beans f"ur die Schnittstellen der Dom"anenschicht in der Konfigurationsdatei von {\em Spring} registriert werden. Die erste Bean in der Liste \ref{conf:syssp} deklariert eine Instanz der Klasse {\em NopEngineRepImp}, die das Interface {\em INopEngineRep} implementiert. Sie verf"ugt "uber die in der Liste \ref{conf:pt} definierten Bean {\em persistenceTool}. Diese Bean wird als eine Eigenschaft in der zweiten Bean {\em nopEngine} hinzugef"ugt, die eine Realisierung des Interfaces {\em INopEngine} ist. Sie wird als die Schnittstelle der Dom"anenschicht dargestellt.\\
\includeXml{chapters/implement/integration.xml}{Integrieren der Schnittstellen der Dom"anen- und Perisstenzschicht}{conf:syssp}
Damit werden die Schnittstellen der Dom"anen- und Persistenzschicht vollst"andig durch {\em Spring} integriert. Dadurch wird eine lauff"ahige Instanz der Klasse {\em nopEngine} f"ur die Pr"asentationsschicht zur Verf"ugung gestellt.
\section{Aufbauen der Web-Seiten mit JSF}
{\em JSF} verf"ugt auch "uber eine eigene Konfigurationsdatei, die normalerweise\footnote{Der Name der Konfigurationsdatei kann beliebig sein. Im Vergleich zur faces-config.xml muss der Name explizit deklariert werden.} faces-config.xml genannt wird, und die verwalteten Beans, Converters bzw. Navigationsregeln\footnote{Die Begriffe verwaltete Beans, Converter und Navigationsregeln werden im Abschnitt \ref{section:jsf} erl"autert.} verwaltet. Diese ist so wichtig, dass die H"afte der Arbeit zur Implementierung der Pr"asentationsschicht darin besteht, diese Datei zu pflegen. Im Folgenden wird gezeigt, wie das {\em JSF}-Frontend der NOP-Engine durch diese Datei konfiguriert bzw. gesteuert wird.
%\includeXml{chapters/implement/jsfConf.xml}{Konfiguration von JSF}{conf:jsf}
%In der Liste \ref{conf:jsf} steht das Wurzel-Element dieser Datei. Dabei werden auch die Namensr"aume bzw. die Version der verwendeten JSF definiert.
\subsection{Konfigurieren von JSF zur Anwendung der Beans von Spring}\label{section:spinjsf}
{\em Spring} bietet einen starken Mechanismus und umfangreiche Werkzeuge zur Verwaltung der Objekte bzw. ihrer Abh"angigkeiten an. In unserem Projekt werden die meisten Objekte unter {\em Spring} verwaltet. Zur direkten Anwendung solcher Beans in {\em JSF} steht {\em DelegatingVariableResolver} von {\em Spring} zur Verf"ugung. Der folgende Code dient zum Zugreifen der Beans von {\em Spring} in {\em JSF} und soll in der Konfigurationsdatei von JSF unter dem Wurzel-Element hinzugef"ugt werden.\\
\includeXml{chapters/implement/spring_in_jsf.xml}{Konfiguration zur Anwendung der Beans von Spring in JSF}{conf:bean}
Dann werden die Beans von {\em Spring} bei der Initialisierung der Konfiguration von {\em JSF} gleichzeitig automatisch geladen. So wie in der Liste \ref{conf:bean} dargestellt wird die vordefinierte Bean {\em nopEngine} unter {\em Spring} direkt f"ur die verwaltete Bean {\em systemController} unter JSF als eine Eigenschaft zur Verf"ugung gestellt.
\subsection{Konfigurieren der verwalteten Beans}
Der folgende Codeblock zeigt, wie man eine Instanz des Front-Controllers {\em systemController} als eine verwaltete Bean in {\em JSF} konfiguriert. Zwischen den Zeilen 2 und 3 wird der vollst"andige Klassenname bzw. der Name der Bean definiert. Ausgehend von der Definition soll dieser {\em systemController} f"ur die Response der Ereignisse aller Web-Seiten zur Verf"ugung stehen. Deswegen wird der Lebenszyklus dieser Bean f"ur eine ganze Web-Session in der Zeile 4 deklariert. Dabei beschreibt der Ausdruck {\em $\#\{nopEngine\}$} eine unter {\em Spring} verwaltete Bean {\em nopEngine}, die als eine Eigenschaft des {\em systemController} dargestellt wird.\\
\includeXml{chapters/implement/managedBean.xml}{Konfiguration von verwalteten Beans in JSF}{conf:bean}

\subsection{Anwendung der JSF-Komponenten zur Darstellung der verwalteten Beans}
{\em JSF} bietet umfangreiche vordefinierte Komponenten zum Aufbauen der Web-Seiten an, die sich in zwei Gruppen aufteilen lassen. Eine Komponente, die mit "`h:"' angef"angt, stellt eine oder eine Menge von  entsprechenden HTML-Elementen dar. Falls sie mit "`f:"' angezeigt wird, ist es eine spezielle Komponente aus {\em JSF}, die normalerweise nichts darstellt, sondern eine gewisse Aufgabe erf"ullt, z.B. ein Validator. Die zwei Vorsilben sollen am Anfang einer {\em JSF}-Seite eingef"uhrt werden. so wie im folgenden Codeblock \\
\includeJsp{chapters/implement/prefix.jsp}{Einstellung der Vorsilben der Komponenten von JSF}{jsf:prefix}
In {\em JSF} steht jede Komponente f"ur die Darstellung eines Objekts zur Verf"ugung, das eine verwaltete Bean oder ihre Eigenschaft ist. Damit wird eine automatische Ladung der Objekte durch verwaltete Beans erm"oglicht. In unserem Projekt werden die folgenden Komponenten zur Erf"ullung der Anforderung der Pr"asentationsschicht verwendet.
\subsubsection{Eingeben der Informationen durch {\em h:inputText}}
Zum Ausw"ahlen eines NOPs oder NOP-Projekts muss man die notwendigen Informationen eingeben, die die Bedingungen zum Herausfinden solcher Objekte sind. Daf"ur steht die Komponente {\em h:inputText} von JSF zur Verf"ugung.\\
\includeJsp{chapters/implement/inputtext.jsp}{Erstellen einer \kc{h:inputText} Komponente von JSF}{jsf:inputtext}
Das Attribut {\em value} wird mit der Eigenschaft {\em name} einer Instanz vom \kc{NopProject}durch den Ausdruck $\#\{systemController.project.name\}$ verbunden. Diese Instanz soll unter der verwalteten Bean {\em systemController} stehen. Wenn man etwas in dieser Komponente eingibt, wird die Eingabe automatisch als der Name des NOP-Projekts gespeichert. In der Zeile 2 steht eine spezielle Komponente von JSF, die nichts darstellt, sondern die L"ange der Eingabe kontrolliert. Diese Komponente ist ein von JSF vordefinierte Validator. Durch das Attribut {\em minimum} und {\em maximum} dieses Validators wird die L"ange der Eingabe der Komponente {\em h:inputText} auf zwischen 2 bis 50 beschr"ankt. Wenn diese Bedingung nicht erf"ullt ist, wird eine Fehlermeldung auf der Web-Seite angezeigt.
\subsubsection{Darstellung der Informationen durch {\em h:outputText}}
Zur Darstellung der Informationen steht in JSF die Komponente {\em h:outputText} zur Verf"ugung. In der Liste \ref{jsf:output} ist ein Beispiel, um den Wert der Eigenschaft {\em paramA} einer Strategie anzuzeigen.
\includeJsp{chapters/implement/output.jsp}{Erstellen einer \kc{h:outputText} Komponente von JSF}{jsf:output}
\subsubsection{Selektieren eines Terms durch {\em h:selectOneMenu}}
Um eine Funktion f"ur den Parameter $f$ oder eine Seitenregel f"ur eine Strategie auszuw"ahlen wird die Komponente {\em h:selectOneMenu} verwendet, die das HTML-Element {\em SELECT} verpackt, und eine Dropdown-Liste darstellt. Das spezielle {\em JSF}-Element {\em f:selectItems} deklariert, dass die zu selektierenden Terme dieser Dropdown-Liste aus der Eigenschaft {\em pageRuleList} vom {\em systemController} herausgeholt werden sollen.
\includeJsp{chapters/implement/select.jsp}{Erstellen einer \kc{h:selectOneMenu} Komponente von JSF}{jsf:select}
\subsubsection{Bestimmen durch {\em h:commandButton}}
Zum Bestimmen einer Fehlermeldung, einer Berechnung von NOPs, des Anlegens oder Speicherns eines NOP-Projekts und des Anzeigens eines NOPs wird die Komponente {\em h:commandButton} verwendet. In der Liste \ref{jsf:button} steht ein Button, der eine Fehlermeldung bestimmen, und danach die Methode {\em goHome} vom {\em systemController} aufrufen kann.
\includeJsp{chapters/implement/button.jsp}{Erstellen einer \kc{h:commandButton} Komponente von JSF}{jsf:button}
\subsubsection{Darstellung eines NOPs durch {\em h:dataTable}}
Zur Darstellung eines NOPs wird die Komponente {\em h:dataTable} von {\em JSF} ausgew"ahlt. So wie in der Liste \ref{jsf:table} dargestellt, haben wir zwei Spalten f"ur diese Tabelle durch {\em h:column} definiert, in denen die Namen der Themen und ihre Gewichte in Bezug auf ein gewisses NOP angezeigt werden. Die spezielle Komponente {\em f:facet} stellt den Text eines Spaltenkopfes dar. Diese Tabelle wird mit einer Liste {\em nopValueList} vom {\em systemController} verbunden, in der jedes Element als ein Paar (Thema-Name, Thema-Gewicht) dargestellt wird. Das Attribut {\em var} definiert eine Variable mit dem Namen {\em nopValue}. Bei der Initialisierung dieser Komponente werden alle Elemente in der Liste {\em nopValueList} mit dieser Variable eines nach dem anderen ausgelesen, und die zwei Werte jedes Paares in der entsprechenden Spalte dieser Tabelle eingetragen.\\
\includeJsp{chapters/implement/table.jsp}{Erstellen einer \kc{h:dataTable} Komponente von JSF}{jsf:table}
\subsection{Navigieren der Web-Seiten durch Navigationsregeln}
Die Umleitungen zwischen den Web-Seiten sollen in {\em JSF} als Navigationsregeln statisch in der Konfigurationsdatei geschrieben werden. Im folgenden Codeblock wird eine Umleitung von der Seite "`index.jsp"' auf die Seite "`createProject.jsp"' definiert, und soll durch den Aufruf der Methode {\em createNop} vom {\em systemController} ausgel"ost werden.
\includeXml{chapters/implement/navi.xml}{Navigationsregel f"ur JSF}{jsf:navi}
F"ur die NOP-Engine werden alle Umleitungen als Navigationsregeln so wie in der Liste \ref{jsf:navi} dargestellt konfiguriert, und durch die Event-Handler (Methoden) unter dem {\em systemController} verwaltet.
\subsection{Anwendung der Konvertern zur Anpassung der darzustellenden Objekte und JSF-Komponenten}
In {\em JSF} werden eine Reihe von Konvertern definiert, die f"ur die "Uberpr"ufung der Eingaben in einer Input-Komponente zur Verf"ugung gestellt werden. Trotzdem muss man den eigenen Konverter zur speziellen Anwendung implementieren. Zum Erstellen eines NOP-Projekts muss eine Seitenregel ausgew"ahlt werden, die in Java als ein {\em enum-}Typ implementiert wird. Der Konverter f"ur {\em String} und {\em enum} ist in JSF nicht vorhanden. Wir erstellen einen  neuen Konverter {\em PageRuleConverter}, der das Interface \kc{Converter}von {\em JSF} bzw. dessen zwei Schnittstellen realisiert, so wie im folgenden Code dargestellt.\\
\includeJavaCode{chapters/implement/converter.java}{Implementierung eines Konverters f"ur eine {\em enum-}Typ}{jc:converter}
Zur Anwendung dieses Konverters muss man ihn in der Konfigurationsdatei von {\em JSF} registrieren. Dabei sind ein darzustellender Name und der vollst"andige Klassenname des Konverters erforderlich. Der Codeblock in der Liste \ref{jsf:converter} beschreibt die Einstellung des Konverters {\em PageRuleConverter} f"ur {\em JSF}.\\
\includeXml{chapters/implement/converter.xml}{Registrierung eines Konverters in JSF}{jsf:converter}
\section{Konfigurieren des Applikationsservers f"ur das Gesamtsystem}
Das Gugubarra-System l"auft auf dem Applikationsserver Tomcat, in dem alle Konfigurationsinformationen in einer XML-Datei "`web.xml"' ausgelagert bzw. verwaltet werden. Normalerweise wird diese Datei f"ur eine Web-Site automatisch generiert, um die trivialen Funktionalit"aten des Servers zu verwenden. Zur Erweiterung der Funktionalit"aten des Servers, sowie zur Anwendung von JSF und Spring, soll man die weiteren zus"atzlichen Einstellungsbl"ocke in dieser Datei hinzuf"ugen. 
\subsection{Konfigurieren einer Web-Site auf dem Server Tomcat zur Anwendung von JSF}
Zur Anwendung von {\em JSF} auf dem Tomcat-Server muss zun"achst ein Servlet-Element, das einen Parser {\em FacesServlet} zur Analyse der {\em JSF}-Seiten deklariert, in der Datei "`web.xml"' hinzugef"ugt werden. Der folgende Codeblock beschreibt diese Registrierung, und deklariert, dass alle Dateien unter dem Verzeichnis /faces/ als {\em JSF}-Seiten betrachtet, und vor der Darstellung durch den registrierten Parser analysiert werden sollen.\\
\includeXml{chapters/implement/webJsf.xml}{Konfiguration von JSF}{conf:webJsf}
\subsection{Konfigurieren einer Web-Site zur Anwendung von Spring}
Um die Funktionalit"aten von {\em Spring} in einer Web-Site zu verwenden, steht die Klasse {\em ContextLoaderListener} in {\em Spring} zur Verf"ugung. Dabei soll ein neues Listener-Element zum Registrieren dieser Klasse in der Datei "`web.xml"' deklariert werden. Der Code zwischen der Zeile 1 und 4  in der Liste \ref{conf:webSpring} dient zur Lokalisierung der Konfigurationsdatei von {\em Spring}. Damit werden alle unter {\em Spring} verwalteten Beans beim Starten des Servers gleichzeitig initialisiert. Zur Anwendung dieser Beans braucht man keine weiteren expliziten {\em Java}-Codes zu schreiben. Man kann darauf  einfach durch den Ausdruck $\#\{ ... \}$ zu zugreifen, so wie in der Liste \ref{conf:bean} dargestellt.\\
\includeXml{chapters/implement/web_spring.xml}{Konfiguration von JSF}{conf:webSpring}


\section{Zusammenfassung}
Dieses Kapitel stellt die modernen {\em Java}-Frameworks, sowie {\em Spring}, {\em JSF} bzw. {\em Hibernate} vor, und gibt eine ausf"uhrliche Beschreibung der Implementierung der NOP-Engine mit einem Schichtenmodell von DDD durch die Anwendung dieser Frameworks. Dabei wird noch das Problem zur Historisierung der Aktionen, Zonen bzw. NOP's gel"ost. Im folgenden Kapitel werden die bei der Implementierung parallel ausgef"uhrten Tests zum "Uberpr"ufen der Korrektheit der Funktionalit"aten der NOP-Engine detailliert beschrieben.


